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1.  SUMMARY 

This  paper  describes  how  to  design  open  computer 
systems  for  mission  critical  applications  within  the 
avionics  of  military  aircraft  using  “Commercial  Off  The 
Shelf  ‘ (COTS)  computer  components1.  Design  aspects  of 
“Integrated  Modula  Avionics”  (IMA)  are  incorporated. 
How  these  aspects  contribute  to  an  effective  obsolescence 
management  is  also  described.  The  content  of  this  paper  is 
presented  within  the  context  of  projects  currently  running 
at  the  European  Aeronautic  Defence  and  Space  (EADS) 
Deutschland  GmbH,  Military  Aircraft  Business  Unit 
(MABU),  which  are  dealing  with  the  subjects  COTS  and 
obsolescence. 

First  the  primary  design  aspects  of  open  computer  systems 
will  be  discussed  as  well  as  internationally  recognised 
associations  and  standards  dealing  with  this  topic.  The 
potential  behind  the  use  of  open  computer  systems  for 
future  avionics  of  military  aircraft  is  to  be  unveiled. 

It  will  be  described,  how  to  set  up  open  computer  systems, 
considering  IMA  conform  design  aspects,  which  fulfil  the 
requirements  directed  to  the  equipment  of  mission  critical 
avionics  in  military  aircraft.  Within  this  context  the  core 
aspects  of  IMA  will  be  introduced  and  compared  to 
conventional  systems. 

Regarding  design  aspects  for  open  computer  systems  the 
design  principals  developed  by  the  Allied  Standard 
Avionics  Architecture  Council  (ASAAC)  have  to  be 
mentioned.  Firms  of  the  three  participating  countries  - 
England,  France  and  Germany  - are  co-operating  to  set  up 
a European  accepted  standard  for  avionics  HW  and  SW 
designed  for  use  in  military  aircraft. 

The  use  of  COTS  computer  HW  and  SW  will  be 
presented  as  a cost  effective  solution  for  setting  up  open 
computer-systems  for  use  in  aircraft,  until  ASAAC 
conform  HW  and  SW  solutions  are  available.  Possible 
COTS  based  configurations  will  be  discussed  referring  to 
a current  COTS  computer  system.  This  system  is 
ruggedised  for  flight  and  built  up  with  COTS  HW  and  run 
by  a COTS  real  time  operating  system.  Successful  flight- 
testing of  the  system  has  taken  place. 

Due  to  the  rapid  developing  IT  technology,  today’s 
computer  systems  quickly  face  obsolescence.  Avionics  for 
military  aircraft  are  especially  vulnerable  because  of  the 


1 Thereby  processor-boards,  I/O-boards,  chassis,  operating  systems  etc. 

are  referred  to,  which  are  available  fully  developed  at  the  commercial 
market. 


long  development  cycles.  The  opportunities  of  managing 
obsolescence,  given  by  the  use  of  COTS  computer  HW 
and  SW,  are  identified  with  respect  to  future  avionics  of 
military  aircraft.  Affected  qualification  and  flight- 
clearance  aspects  as  well  as  the  porting  of  avionics  SW- 
applications,  originally  developed  for  proprietary 
computer  systems,  onto  COTS  computer  systems  will  be 
mentioned. 

2.  OPEN  SYSTEM  ARCHITECTURES 

The  majority  of  computing  systems  in  service  in  military 
aircraft  of  today,  show  a proprietary  system  architecture2. 
They  are  designed  as  Line  Replaceable  Units  (LRUs) 
developed  for  special  functions  or  cover  a cluster  of 
functions.  Fitted  together  in  the  avionics  of  the  EF2000, 
LRUs  can  be  found  for  example  as  DASS  computer,  as 
navigation  computer,  as  digital  symbol  generator  etc. 
(Figure  1).  Mostly  HW  and  OS  of  these  LRUs  are 
invariant.  Therefore  modifications,  as  well  as 
enhancements  and  technical  innovations,  that  become 
necessary  during  the  life  cycle  of  a LRU,  maybe  can’t  be 
carried  out.  Any  cross  use  of  proprietary  computer 
systems  for  different,  mission-critical  avionics  functions 
may  not  be  practicable  due  to  their  specific  system  design. 
Each  function  is  implemented  on  a specially  developed 
computer  system,  integrated  as  LRU  in  the  aircraft 
avionics. 

Today  avionics  systems  of  military  aircraft,  based  on 
LRUs  designed  for  special  functions,  represent  a 
symbiosis  of  multiple  LRUs.  Thereby  the  high  complexity 
of  avionics  systems,  due  to  their  comprehensive 
functionality,  is  further  driven  by  the  specific  properties 
of  the  different  LRUs  - proprietary  external  HW 
interfaces,  data-protocols  etc..  Development,  production, 
integration  testing,  logistics,  maintenance  and  upgrading 
of  today’s  avionics  systems  are  therefore  comprehensive 
and  cost  intensive  over  the  whole  lifecycle. 

2.1  Main  Design- Aspects 

Pushed  by  the  described  deficits  of  current  LRUs,  open 
system  architectures  are  required  for  future  avionics  of 
military  aircraft.  The  core  aspect  of  open  systems  is  a 
flexible  system  design  based  on  well  established  HW  and 


2 Today’s  avionics  computer  already  follow  a modulare  HW  and  SW 
design.  However  modules  and  components  are  coupled  via  supplier 
specific  HW  and  SW  interfaces. 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components”,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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SW  interfaces.  By  using  open  systems  it  is  expected  [1]  to 
overcome  the  deficits  of  current  LRUs: 

• Avionics  equipment  following  flexible  HW  and  SW 
concepts  shall  support  the  use  of  state  of  the  art 
technology. 

• An  open  architecture  can  shorten  equipment 
development  and  secure  the  upgrade  potential  needed. 

• The  scope  of  possible  HW  and  SW  solutions  will 
grow. 

• A well  established  upgrade  potential  and  enhanced 
resource  procurement  shall  help  to  reduce  the 
pressing  obsolescence  risks  encountered  with  current 
avionics  equipment. 

• Development,  procurement  and  lifecycle  costs  can  be 
significantly  reduced. 

• The  integration  of  components  into  an  equipment  as 
well  as  the  integration  of  equipment  into  an  existing 
network,  like  the  avionics  of  a military  aircraft,  shall 
be  eased. 

• The  previously  described  scope  of  open  system 
architectures  is  established  via  HW  and  SW  offered  in 
the  commercial  market. 

Applied  to  computer  systems  for  the  avionics  of  military 
aircraft  this  implies  the  following  focal  aspects  for  an 
open  system  design  [2]  to  be  considered  during  the 
definition  phase  of  a computer  system: 

• A modular  system  design  with  mechanical  and 
electronic  autonomous  components3,  similar  to  that  of 
modern  LRUs,  has  to  be  followed. 

• The  integration  of  such  components  into  a 
functioning  system  has  to  follow  clearly  defined,  fully 
developed,  commercially  supported  and  therefore 
stable  HW  and  SW  interfaces.  This  refers  to  both 
external  and  internal  HW  and  SW  interfaces. 

• HW  and  SW  interfaces  chosen  for  open  system 
architectures  have  to  be  available  to  a broad  clientele 
of  users  and  should  be  continuously  maintained  and 
further  developed  by  internationally  recognised 
standardisation  institutions. 

• HW  and  SW  interfaces  suited  for  open  computer 
systems  have  to  support  modifications  and  upgrades 
of  existing  and  future  avionics  applications. 

• The  HW  configuration  of  open  computer  systems 
must  feature  quick  and  easy  maintenance  and  upgrade 
possibilities,  e.g.  well  established  interfaces,  which 
guarantee  the  exchangeability  of  inoperative  or 
obsolete  components,  boards  and  parts  against  state- 
of-the-art  solutions.  Within  chassis  spare  slots  must 
be  available  for  the  insertion  of  additional  boards. 

2.2  International  Efforts 

Efforts  to  establish  open  systems  in  military  equipment 
find  their  origin  in  the  USA.  They  were  initiated  by 
William  Perry,  1994  Secretary  of  Defense  and  a strong 
advocate  of  an  intensive  usage  of  commercially 


3 Such  components  are  designed  as  Embedded  Systems,  e.g.  as  SBC, 

combining  dedicated  equipment  functions. 


established  standards,  specifications  and  state-of-the-art 
technology. 

The  same  year  Dr.  Kaminski,  Under  Secretary  of  Defense 
for  Acquisition  & Technology,  strengthened  this  direction 
when  announcing,  that  new  acquisitions  of  electronic 
equipment  have  to  follow  an  open  system  architecture.  To 
support  this  process  he  founded  the  Open  Systems  Joint 
Task  Force  (OS-JTF)  and  established  it  as  an  institution. 

Due  to  this  announcement  of  the  Department  of  Defense 
(DoD)  concerning  military  command,  control, 
communications,  computer  and  intelligence  (C4I) 
systems,  documents  were  set  up,  which  describe 
definition,  specification  and  development  guidelines  for 
open  systems  as  well  as  the  related  HW  and  SW 
interfaces.  Leading  documents  related  to  this  topic  are  [3]: 

• Joint  Technical  Architecture  (JTA)  framework 

• Joint  Aeronautical  Commanders  Group  (JACG)  guide 
specifications 

• Generic  Open  Architecture  (GOA)  framework 

• Technical  Reference  Codes  (TRCs) 

• Technical  Architecture  Framework  for  Information 
Management  (TAFIM),  cancelled  in  January  2000 
and  replaced  by  the  current,  equivalent  JTA 
standards. 

By  the  Institute  of  Electrical  and  Electronic  Engineers 
(IEEE)  open  systems  are  defined  via  two  basic  standards: 

• P 1 003 .0/D  1 5 Open  Specification4 

• P 1 003 .0/D  1 6 Open  System  Environment 

These  standards  are  accompanied  by  further  IEEE 
standards. 

2.3  Potential  for  Realisation 

Open  systems  are  principally  suited  for  all  kinds  of 
avionics  systems  in  military  aircraft.  Due  to  the  strong 
adherence  of  open  architectures  to  well  established 
interfaces,  avionics  computer  systems  are  especially 
suited  for  first  introduction.  HW  and  SW  computer 
components  have  experienced  a broad  entry  in  many 
different  industries.  An  intensive  competition  between  the 
different  suppliers  of  computer  components  has  led  to 
standardised  HW  and  SW  interfaces,  which  were  quickly 
and  widely  accepted,  e.g.: 

• VME,  PCI  or  cPCI  are  well  established  data-bus 
interfaces  for  coupling  different  computer 
components 

• ATR  is  a standard  for  chassis,  ruggedised  for  flight 

• As  standard  format  for  the  geometry  of  computer 
boards  Eurocard  is  used 

• POSIX  is  established  as  SW  standard  for  application 
and  user  interfaces 

Regarding  this  selection  of  standards  already  helps  to  fit 
together  HW  and  SW  components  according  to  the 
principals  of  open  system  architectures,  summarised  by 


4 “Public  specifications  that  are  maintained  by  an  open,  public 
consensus  process  to  accommodate  new  technologies  over  time  and 
that  are  consistent  with  international  standards”,  Open  Specification 
Definition  IEEE  P1003.0/D15.. 
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the  OS-JTF  [1]  in  the  Electronics  Reference  Model 
(Figure  2).  A central  design  aspect  of  this  model  is  a 
layered  HW  and  SW  architecture.  The  single  layers  of  this 
model  can  communicate  with  each  other  via  the  SW  and 
HW  interfaces  listed  above.  A computer  system,  based  on 
the  layered  architecture  of  the  Electronics  Reference 
Model,  is  open  for  the  exchange  of  single  HW  and  SW 
computer  components.  This  helps  to  reduce  obsolescence 
risks  associated  with  computer  systems. 

Computer  HW  and  OSs,  which  satisfy  the  standards  listed 
above  and  classified  as  ruggedised  for  flight,  can  be 
bought  on  the  commercial  market.  Future  aircraft 
programs  as  well  as  facing  upgrades  of  aircraft  in  service 
may  use  existing  COTS  computer  HW  and  SW  to  design 
open  computer  systems  for  use  in  military  aircraft. 
Existing  and  newly  developed  avionics  SW  applications 
have  then  to  be  aligned  to  a layered  architecture, 
described  by  the  referred  Electronics  Reference  Model. 

A first  approach  will  have  to  be  restricted  to  mission 
critical  computer  systems  to  reduce  the  risk  always 
associated  with  the  introduction  of  new  technologies. 

3.  KORRELATION  WITH  INTEGRATED 
MODULAR  AVIONICS  (IMA) 

Design  principals  of  open  systems  conform  with  the  basic 
principals  of  Integrated  Modular  Avionics,  although  IMA 
goes  much  further. 

Regarding  the  actual  needs  of  aircraft  operators  IMA  [4] 
propagates  modular  architectures  for  avionics  systems. 
Intentions  of  IMA  are: 

• Improved  maintenance  of  Avionics  systems. 
Adaptations  and  enhancements  during  the  lifecycle  of 
avionics  systems  have  to  be  simplified  . 

• To  introduce  a refined  fault  tolerance  and  fault 
management  for  avionics  systems  concerning 
detection,  isolation  and  correction  of  in  flight  faults. 

• To  take  advantage  of  shorter  technology  development 
cycles  for  avionics. 

Applied  to  the  HW  of  avionics  computers  IMA  conform 
configurations  will  consist  of  components  coupled  via  few 
dedicated  HW  and  SW  interfaces.  These  interfaces 
comply  with  international  established  standards.  Within 
such  computer  systems,  components  can  easily  be 
exchanged  and  replaced  by  further  or  completely  new 
developed  components.  Due  to  that,  obsolescence  risks 
are  reduced.  A further  central  design  aspect  derived  from 
IMA  is  to  build  up  component  clusters  within  cabinets5, 
which  serve  as  data  management  centres.  Step  by  step  this 
development  direction  of  avionics  computers  has  then  to 
be  applied  to  further  avionics  systems.  Therefore,  in  the 
future  the  design  of  military  avionics  will  no  longer  be 
determined  by  multiple,  separate  computer  systems  or 
LRUs,  coupled  via  data-busses  and  point-to-point 
connections.  Consequently  the  diversity  of  electronic 
components  in  today’s  chassis  respectively  LRUs  will  be 


reduced.  Instead  common  modules,  components  which  are 
available  in  a few  variants  only,  will  handle  different 
avionics  functions.  These  common  modules  will  be 
mounted  in  a small  number  of  cabinets,  connected  via 
high  speed  data-busses,  operating  with  a high  bandwidth. 
In  case  of  an  in  flight  HW  or  SW  failure,  an  in  flight 
reconfiguration  of  the  avionics  system  enables  avionics 
functions  to  be  maintained,  depending  on  the  severity  of 
the  failure  that  has  occurred  and  the  necessity  of  a 
function  for  save  aircraft  operation.  Thereby  a greater 
redundancy  of  avionics  functions  is  reached  with  less 
components  compared  to  the  number  of  components 
needed  for  redundancy  purposes  in  today’s  avionics 
systems. 

Associated  with  avionics  SW,  IMA  follows  a strict 
subdivision.  It  distinguishes  between  SW  applications  for 
pure  avionics  functions,  the  OS  and  the  driver  SW  for 
operating  the  HW  components  of  an  equipment.  These 
three  autonomous  SW  components  are  related  via  highly 
standardised  SW  interfaces  and  together  make  up  the  SW 
of  an  avionics  equipment. 

Avionics  equipment  following  IMA  design  aspects  shows 
a modular  system  architecture,  based  on  few  variants  of 
common  HW  and  SW  components,  which  can  be  used  for 
different  avionics  applications.  The  subdivision  of  the  SW 
of  an  avionics  equipment  as  well  as  the  communication 
between  the  equipment’s  HW  components  via  well 
established,  highly  standardised  interfaces,  e.g.  VME, 
cPCI  etc.,  lead  to  an  equipment  architecture,  classified  by 
SW  and  HW  layers.  These  layers  are  again  coupled  via 
well  established,  highly  standardised  interfaces  and  make 
up  the  technical  layout  of  modern  IMA  avionics 
equipment.  Such  a layered  architecture  corresponds  with 
the  Electronics  Reference  Model  mentioned  in  Chapter 
2.3  as  an  architecture  for  open  systems.  Therefore  this 
model  can  be  referred  to  as  a development  step  for  current 
avionics  towards  IMA. 

Looking  beyond  the  establishment  of  open  systems, 
ASAAC  is  producing  a set  of  IMA  implementation 
standards.  ASAAC  is  run  by  aerospace  and  IT  companies 
in  a tri  national  alliance  between  the  participating 
countries  England,  France  an  Germany. 

4.  IMPLEMENTION  GUIDELINES  FOR  OPEN 
SYSTEM  ARCHITECTURES 

Currently  two  different  implementation  concepts 
correlating  with  each  other,  ASAAC  and  COTS,  are 
followed  by  EADS  Deutschland  GmbH  to  introduce  open 
systems  in  military  aircraft  avionics.  Both  concepts  follow 
different  priorities  and  time  scales.  ASAAC  is  directed  to 
the  long-term  and  focused  on  a completely  IMA  reliant 
avionics  in  military  aircraft.  Until  ASAAC  conform  HW 
and  SW  components  are  available,  future  configurations 
of  avionics  computer  can  make  use  of  COTS.  The  focus 
of  this  concept  is  short-term,  propagating  a cost  saving 
introduction  of  open  systems  in  avionics,  thereby 
contributing  to  the  mitigation  of  the  obsolescence  risks 
related  with  current  avionics  systems. 


Contrary  to  chassis  in  service  today,  cabinets  are  part  of  the  aircraft 
structure  and  represent  mounting  areas  for  a number  of  processor 
boards,  I/O  boards  etc.. 
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4.1  ASAAC 

ASAAC  is  working  towards  the  establishment  and 
demonstration  of  standards  for  defining  the  architecture  of 
modular  avionics  for  military  aircraft  within  the  next  four 
years.  First  ASAAC  related  HW  and  SW  components 
shall  be  available  on  the  commercial  market  in  2005.  In  a 
next  step  the  ASAAC  standards,  agreed  by  the  three 
European  partner  nations,  shall  become  NATO  standard 
(STANAG).  Focal  point  of  all  ASAAC  efforts  towards 
modular  avionics  for  military  aircraft  is  a layered  HW  and 
SW  architecture  (Figure  3).  Within  ASAAC,  the 
Electronics  Reference  Model,  referred  to  in  chapter  2.3  as 
layered  architecture  model  for  open  system  designs,  is 
experiencing  a refinement.  The  Application  Layer  (AL)  is 
the  upper  layer  of  the  ASAAC  architecture  model, 
containing  all  SW  applications  dealing  with  pure  avionics 
functions  as  well  as  application  dependent  SW  modules 
for  data  management  and  communication.  Beneath  the  AL 
the  Operating  System  Layer  (OSL)  is  placed,  comprising 
the  operating  system  and  general  SW  modules  for  system 
management  and  communication  purposes.  Within  the 
ASAAC  architecture  model  the  Module  Support  Layer 
(MSL)  is  the  lowest  SW  layer,  closest  to  the  HW.  It  is  a 
cluster  of  HW  related  driver  SW  needed  for  operating  the 
respective  HW.  AL,  OSL  and  MSL  are  coupled  via 
standardised  interfaces  - Application  to  Operating  System 
Interface  (APOS)  and  Module  to  Operating  System 
Interface  (MOS)  - according  to  the  ASAAC  layered 
architecture  model.  APOS  and  MOS  are  defined  with  in 
the  ASAAC  standards. 

System  architectures,  designed  in  layers  according  to  the 
ASAAC  model,  imply  a semi-automatic  configuration  of 
the  HW  and  SW  of  an  avionics  system  by  system  tables, 
so-called  blueprints.  In  these  Blueprints  no  unique  HW 
and  SW  configuration  is  described  but  a variety  of 
configurations,  which  cover  possible  in  flight  failures  of 
single  HW  or  SW  components.  After  an  in  flight  failure 
has  occurred,  an  in  flight  reconfiguration6  of  the 
remaining  HW  and  SW  components  maybe  necessary.  A 
semiautomatic  writing  of  blueprints  is  supported  by  SW 
tools.  Thereby  system  engineers  are  supported  to  develop 
different  configurations  for  the  HW  and  SW  components 
of  an  avionics  system  with  an  affordable  amount  of  effort. 
These  configurations  have  to  cover  the  failure  free  system 
status  as  well  as  possible  failures  of  HW  and  SW 
components  of  an  avionics  system.  During  operation  of  an 
avionics  system,  the  blueprints  are  loaded  as  data  files  in 
the  HW  components  of  an  avionics  system. 

ASAAC  therefore  not  only  defines  standards  for  the 
design  of  open  system  architectures  for  military  aircraft 
avionics  but  also  investigates  SW  tools  for  the  realisation 
and  implementation  of  ASAAC  standards  respectively 
IMA. 


6 After  an  in  flight  failure  occurred,  a reconfiguration  becomes 

necessary,  if  avionics  functions  needed  for  aircraft  operation  are  no 
longer  available  via  the  remaining  HW  and  SW  resources.  If  latter  are 
not  sufficient  to  offer  all  avionics  functions  of  a fully  operable 
avionics  system,  then  avionics  functions  no  longer  needed  for  aircraft 
operation  have  to  be  shut  down.  The  SW  of  avionics  functions 
needed,  then  has  to  be  newly  distributed  onto  the  remaining  HW  by  a 
reconfiguration  of  the  avionics  system. 


Until  ASAAC  conform  HW  and  SW  components  are 
available,  components  offered  on  the  COTS  market  are  an 
adequate  solution.  Then  already  the  next  generation  of 
computer  systems  for  military  aircraft  can  follow  an  open 
system  design.  Simultaneously,  as  discussed  in  chapter  5, 
obsolescence  risks  related  with  such  computer  systems  are 
reduced. 

4.2  COTS 

EADS  MABU  has  designed  a Universal  Aircraft 
Computer  (UAC)  based  on  COTS  components  as  a short- 
term available  computer  system  for  mission  critical 
military  aircraft  avionics,  which  has  an  open  system 
architecture.  The  UAC  is  gaining  increasing  recognition 
for  upgrade  programs  of  in  service  military  aircraft,  the 
design  of  an  avionics  system  for  a new  trainer  aircraft  and 
as  an  answer  to  the  obsolescence  problems  encountered 
with  current  avionics  of  military  aircraft.  Further  more 
severe  cost  restrictions  and  a shrinking  procurement 
market  for  military  ruggedised  computer  systems  [5]  are 
additional  drivers  for  a lasting  use  of  COTS  components. 

4.2.1  Central  Design- Aspects  of  COTS  Computer- 
Systems 

The  UAC  is  designed  as  a multiprocessor  system  for 
mission  critical  avionics  applications.  To  fulfil  this 
requirement,  the  basic  version  of  the  UAC  design 
comprises  a conduction  cooled  VME  backplane  fitted 
1 ATR  chassis,  in  which  the  following  VME  boards7  are 
integrated: 

• three  PPC603e  processor  boards,  two  of  them 
enhanced  with  MlLbusl553B  PCI  mezzanine  cards 
(PMC) 

• one  analog  input  board 

• one  graphic  board 

With  the  UAC  a group  of  external  electronic  interfaces 
can  be  served: 

• RS232 

• Ethernet 

• Discretes 

• Analog  Input 

• RGB 

• MILbusl553B 

• ARINC429 

• ATM 

• Fibre  Channel 

These  interfaces  enable  the  UAC  to  be  integrate  into  the 
avionics  of  military  aircraft. 

For  operating  the  UAC,  the  commercially  available 
realtime  operating  system  LynxOS  is  used.  Driver  SW 
fitting  with  the  chosen  HW  components  is  made  available 
by  the  HW  supplier  for  different  operating  systems.  The 
operating  system  has  to  be  configured  according  to  the 
HW  used.  Since  the  operating  system  is  fitted  with  a 
POSIX  interface,  UNIX  compatible  SW  applications  are 
supported  on  the  UAC. 


7 To  be  integrated  into  the  conduction  cooled  ATR  chassis  of  the  UAC, 
boards  have  to  be  fitted  with  wedge-locks  compliant  with  IEEE 
1 101.2  for  mechanical  fixing. 
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The  HW  components  used  for  the  UAC  have  been 
specified  by  the  supplier  as  ruggedised  according  to  MIL- 
STD,  concerning  physicals  loads  the  system  will 
experience  when  operated  in  military  aircraft.  Therefore 
the  HW  can  resist  extreme  temperature  fluctuations, 
moisture,  vibration,  shock,  EMC  etc..  Supplier  delivered 
CoCs  grant,  that  the  components  are  qualified  for  the 
relevant  physical  loads.  Dependent  on  the  CoCs  is  the 
licensing  of  the  UAC  for  use  in  military  aircraft. 

The  basic  configuration  of  the  UAC  described  above  is 
only  one  possible  configuration  of  the  UAC.  However  the 
system  architecture  of  the  UAC  is  fixed,  which  means  the 
UAC  is  a commercial  VME  based  computer  system 
housed  in  an  ATR  chassis.  This  chassis  then  is  configured 
for  a particular  application  by  use  of  ruggedised  Double- 
Eurocard8  VME  boards.  Further  the  chosen  chassis  has  to 
have  spare  slots,  in  case  the  integration  of  additional  VME 
boards  becomes  necessary  later  on  due  to  enhanced 
functional  requirements.  External  interfaces  of  the  UAC 
are  selected  according  to  the  avionics  system  the  UAC  is 
planned  to  be  integrated  with.  HW,  OS  and  SW-drivers 
are  procured  via  the  COTS  market.  Although  all  HW 
components  of  the  basic  configuration  of  the  UAC  are 
offered  by  one  supplier,  a close  coupling  towards  a single 
supplier  has  not  taken  place. 

Like  with  proprietary  computer  systems,  each  intended 
UAC  configuration  has  to  be  defined  via  requirements  and 
a specification.  Derivatives  of  already  existing  UAC 
configurations  may  then  be  described  via  amendments  to 
existing  documents.  Therefore  time  savings  related  with 
the  use  of  COTS  components  are  mainly  seen  within  the 
development  phase  of  a computer  system.  If  fully 
developed  COTS  components  are  deployed  for  the 
configuration  of  computer  systems,  a development  phase 
as  used  for  proprietary  solutions  will  no  longer  be 
applicable.  However,  the  definition  and  procurement 
phase  can  be  barely  shortened  by  the  use  of  COTS. 
Nevertheless,  the  total  time  needed  to  configure  a COTS 
computer  system  will  be  less  than  that  needed  for  a 
proprietary  solution.  This  implies  cost  savings  parallel  to 
the  lower  procurement  costs  of  COTS  components.  How 
far  LCC  savings  are  possible  with  COTS  solutions  is  part 
of  an  ongoing  investigation. 

4.2.2  Context  to  Open  Systems 

The  UAC  is  built  up  from  commercially  available  HW, 
OS  and  driver  SW,  coupled  via  well  established  HW  and 
SW  interfaces  and  follows  a layered  system  architecture 
like  that  stated  for  open  systems  and  AS  A AC. 

With  VME  as  data-bus  for  inter-board  communication 
and  PCI  as  local  data-bus  for  adding  mezzanine  cards  to 
VME-boards,  well  established  and  therefore  technical 
stable  electronic  interfaces  have  been  chosen  for  the 
architecture  of  the  UAC.  The  stability  of  these  interface 
technologies  becomes  obvious  regarding  the  broad  variety 
of  VME  boards  and  PCI  mezzanine  cards  offered  by  many 


8 The  geometric  dimensions  of  double  Eurocard  boards  are:  233.35 
[mm]  width  * 160  [mm]  height. 


COTS  suppliers.  American  National  Standards  Institute 
(ANSI),  IEEE  and  VMEbus  International  Trade 
Organisation  (VITA),  are  all  well  known  organisations  for 
technical  standardisation  matters,  that  have  maintained  the 
VME-  and  PCI-  standards.  These  interfaces,  the  geometry 
of  the  chassis  and  the  mechanical  board  fixing  guarantee 
the  exchangeability  of  UAC  components  in  the  long-term. 
Enhancements  of  the  UAC  are  supported  by  free  VME 
slots  on  the  VME  backplane  together  with  free  PCI  slots 
on  integrated  VME  boards. 

Know-how  as  well  as  experience  concerning  interfaces, 
HW,  OS  and  driver  SW  of  the  UAC  are  absolutely 
necessary  when  using  COTS  components.  Only  then  is  it 
possible  to  take  advantage  of  the  modification  and 
extension  potential  inherent  to  the  open  architecture  of  the 
UAC.  Plug-and-Play  features  are  commonly  not 
supported  by  COTS  components.  This  mainly  depends  on 
how  strict  COTS  suppliers  adhere  to  established  interface 
standards  in  the  design  of  their  components.  This  is  also  a 
factor  determining  if  COTS-components  from  different 
suppliers  can  be  mixed,  although  they  are  classified  as 
VME  boards  or  PCI  mezzanine  cards. 

The  open  aspect  of  the  UAC  architecture  has  been 
verified  by  using  it  in  different  projects  with  requirements 
that  could  not  be  fulfilled  with  the  basic  UAC 
configuration  (Figure  4).  Therefore  the  PPC603e  board, 
which  within  the  basic  configuration  is  not  fitted  with  a 
MILbus  1553B  PCI  mezzanine  card,  was  replaced  by  a 
PPC750  processor  board.  Additionally  a further  PPC750 
board  was  integrated  into  the  ATR  chassis.  Furthermore  a 
mass  memory  board  was  added  to  the  configuration  and 
the  graphics  board  was  removed.  Only  boards  ruggedised 
for  flight  and  delivered  by  the  same  supplier  as  the  basic 
version  of  the  UAC  were  used  for  these  modifications. 
Within  a another  modification  all  three  PPC603e  boards 
are  replaced  by  PPC750  boards  provided  by  a different 
supplier.  Since  primarily  designed  for  operation  in  an 
industrial  environment,  these  boards  additionally  can  be 
ruggedised  for  flight  by  the  supplier,  if  this  is  a customer 
requirement.  Two  of  these  three  PPC750  boards  will  be 
fitted  with  the  MILbus  mezzanine  cards  delivered  by  the 
supplier  of  the  UAC  basic  version. 

5.  OBSOLESCENCE  MANAGEMENT 

Continuously  shorter  development  cycles  within  the  IT 
industry  accelerates  the  obsolescence  of  IT  products,  with 
their  life  cycles  getting  shorter.  Simultaneously  this 
process  is  accompanied  by  shrinking  government  budgets 
for  military  expenses.  Therefor  an  effective  obsolescence 
management  concerning  the  avionics  of  military  aircraft  is 
gaining  lasting  importance.  Concerning  avionics 
computers,  different  kinds  of  obsolescence  risks  have  to 
be  faced: 

• Already  when  production  of  a proprietary  avionics 
computer  starts,  some  electronics  parts  needed  may 
no  longer  be  available,  because  they  have  become 
obsolete  since  the  development  phase  of  the  computer 
has  been  completed. 
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• The  performance  of  aged  proprietary  computers  may 
no  longer  be  sufficient  to  serve  the  enhanced  needs  of 
today's  avionics  systems.  Since  the  underlying 
technology  of  these  systems  has  not  been  further 
developed,  a system  upgrade  isn’t  possible. 

• Components  or  parts  necessary  to  repair  inoperable 
computer  systems  have  become  obsolete  and  are  no 
longer  available  via  the  respective  market  and  spare 
stocks  built  up  by  the  system  operator  have  been  used 
up. 

Therefore  in  recent  years  international  committees  and 
industry  have  discussed  possibilities  for  an  effective 
obsolescence  management  regarding  the  avionics  of 
military  aircraft.  Open  computer  systems  based  on  COTS 
offer  several  approaches  for  an  effective  obsolescence 
management  of  military  aircraft  avionics,  as  discussed  in 
the  following  chapters. 

5.1  COTS  Base 

Computer  components  offered  on  the  COTS  market 
usually  are  available  in  the  short-term.  Therefore  the 
mentioned  obsolescence  risk  due  to  elapsed  time  between 
development  phase  and  production  start  is  not 
encountered  with  COTS.  Obsolescence  risks 

corresponding  with  an  ageing  computer  system  are 
mitigated  by  the  common  adherence  of  COTS 
components  to  commercially  well  established  HW  and 
SW  interface  standards.  Because  of  competition  COTS 
suppliers  are  strongly  interested,  that  their  components  are 
compatible  with  such  standards.  To  stay  in  business  with 
traditional  customers  and  to  gain  new  customers,  suppliers 
depend  on  the  compatibility  of  their  components  with  the 
products  of  other  suppliers  as  well  as  the  upward  and 
downward  compatibility  of  their  own  components. 

5.2  Layered  Model 

SW  applications,  developed  according  to  the  layered 
ASAAC  model,  can  be  ported  onto  different  HW 
configurations  with  a minimum  amount  of  effort.  Using 
the  ASAAC  standards  allows  for  later  enhancements  and 
modifications  of  the  SW  application  to  be  easy  performed. 
Therefore  a layered  SW  architecture,  as  propagated  in  the 
context  of  open  systems,  helps  to  reduce  costs,  time  and 
effort  caused  by  HW  and  SW  obsolescence,  thereby 
supporting  an  effective  obsolescence  management. 

5.3  Running  Upgrades 

Computer  systems,  which  experience  short  and  regular 
upgrade  cycles,  will  show  only  little  obsolescence 
between  two  successive  upgrades.  As  a result,  upgrades  as 
well  as  interim  maintenance  and  repair  efforts  will  be  less 
complex  and  less  costly.  However  if  upgrades  are  widely 
spaced,  a lasting  obsolescence  of  computer  systems  is 
allowed.  This  will  rise  complexity  and  costs  for  upgrades, 
maintenance  and  repair.  In  the  long-term,  running 
upgrades  will  limit  the  obsolescence  of  computer  systems, 
therefore  being  more  affordable  than  widely  spaced 
upgrades.  Again  the  layered  HW  and  SW  architecture  of 


open  systems  supports  an  effective  obsolescence 
management  when  based  on  running  upgrades. 

5.4  Design  of  Avionics  Systems  by  System  Tables 

A SW  tool,  which  allows  a semiautomatic  system 
configuration  by  writing  system  Blueprint  tables  as 
introduced  in  chapter  4. 1 ASAAC,  can  also  be  used  for  a 
more  effective  obsolescence  management.  However, 
obsolescence  risks  inherent  to  computer  systems  will  not 
be  mitigated.  A respective  SW  tool  simplifies  the 
integration  of  HW  and  SW  modifications,  which  have 
become  necessary  due  to  the  obsolescence  of  a computer 
system.  Developed  for  a better  and  easier  design  of 
complex  avionics  systems,  such  a tool  also  serves  an 
effective  obsolescence  management. 

5.5  Life  Time  Buy 

If  a COTS  supplier  intends  to  stop  support  and  production 
of  a certain  computer  component,  which  has  become 
obsolete,  he  will  probably  offer  his  customers  a Life  Time 
Buy  opportunity  for  this  component  [6].  Therefore 
computer  systems  based  on  COTS  components  enable  a 
refinement  of  traditional  obsolescence  management 
strategies  mainly  relying  on  stock  building.  A customer 
will  no  longer  be  forced  to  determine  and  to  buy  the 
necessary  amount  of  spares,  to  cover  the  whole  life  time 
of  a computer  system,  which  has  just  been  put  into 
service.  He  can  determine  the  amount  of  spares  needed  for 
maintenance  and  repair  when  offered  a Life  Time  Buy 
opportunity  by  the  supplier,  and  thereby  avoids  a costly 
capital  investment  in  stocks.  Furthermore  the  inherent 
uncertainty  about  the  amount  of  spares  needed  will  have 
diminished  at  that  time.  This  alternative  is  adequate  for  an 
effective  obsolescence  management,  especially  if  it 
becomes  obvious,  that  a COTS  computer  system  despite 
his  open  architecture  will  experience  no  more  upgrades 
till  the  end  of  his  service  life. 

6.  RESUME 

COTS  computer  components,  due  to  their  alignment  to 
commercially  established  international  HW  and  SW 
interface  standards,  contain  a lasting  potential  to  introduce 
open  computer  systems  into  the  avionics  of  military 
aircraft.  At  the  same  time  these  computer  systems  will  be 
cheaper  and  better  in  performance  then  proprietary 
solutions.  Generally  even  open  COTS  based  computer 
systems  will  not  fit  Plug-and-Play  design  features.  For  the 
configuration  of  open  computer  systems  based  on  COTS 
components  comprehensive  know-how  is  necessary  about 
the  HW  and  SW  used,  as  well  as  about  the  porting  of 
application  SW  on  different  HW  platforms.  Open,  COTS 
based  computer  systems  for  the  avionics  of  military 
aircraft  are  an  effective  approach  towards  IMA  until 
ASAAC  conform  avionics  equipment  is  available.  The 
scope  for  an  effective  obsolescence  management  is 
already  determined  in  the  design  phase  of  a system.  Open 
COTS  computer  systems  can  help  to  make  this  scope 
given  by  current  technology  as  big  as  possible.  Finally 
however  the  actual  market  request  for  such  systems  will 
determine  the  success  of  this  design  approach. 
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7.  ABBREVIATIONS 

AL  Application  Layer 

ANSI  American  National  Standards  Institute 

API  Application  Program  Interface 

APOS  Application  to  Operating  System  Interface 

ASAAC  Allied  Standard  Avionics  Architecture  Council 
ATR  Air  Transport  Rack 

C4I  Command,  Control,  Communications, 

Computers  and  Intelligence 
CoC  Certificate  of  Conformance 

COTS  Commercial  Off  The  Shelf 

cPCI  Compact  PCI 

DASS  Defensive  Aid  Subsystem 

DoD  Department  of  Defense 

EMC  Electromagnetic  Compatibility 

GOA  Generic  Open  Architecture 

HW  Hardware 

IEEE  Institute  of  Electrical  and  Electronic  Engineers 

IMA  Integrated  Modular  Avionics 

I/O  Input  / Output 

IT  Information  Technology 

JTA  Joint  Technical  Architecture 

LCC  Life  Cycle  Costs 

LRU  Line  Replaceable  Unit 

MABU  Military  Aircraft  Business  Unit 

MOS  Module  to  Operating  System  Interface 

MSL  Module  Support  Layer 

OEM  Original  Equipment  Manufacturer 

OS  Operating  System 

OS-JTF  Open  Systems  Joint  Task  Force 

OSL  Operating  System  Layer 

PCI  Peripheral  Component  Interconnect 

PMC  PCI  Mezzanine  Card 

POSIX  Portable  Operating  System  Interface 

PPC  Power  Processor 

SBC  Single  Board  Computer 

STANAG(NATO)  Standardisation  Agreements 

SW  Software 

TAFIM  Technical  Architecture  Framework  for 

Information  Management 
UAC  Universal  Aircraft  Computer 

VITA  VMEbus  International  Trade  Organisation 

VME  Versatile  Module  Europe 
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Figure  2:  OS-JTF  Electronics  Reference  Model 
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Figure  3:  ASAAC  model  for  layered  system  architectures 
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Figure  4:  COTS  Computer  with  an  open  system  architecture 
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